matkalkyl
dev

Denna sida är tillägnad utvecklingen av Matkalkyl.se. En ny version är fortfarande på gång. Du kan alltid komma till denna sida för den senaste informationen.
Projektet utvecklas och underhålls av Fredrik.
Nyhetsbrev
Jag har inte riktigt kommit i gång med regelbundna nyhetsbrev, men de kommer med tiden.
📬 Senaste: 2 Juni 2025
Inblick
Referensmaterial för systemet
Referens över all programkod och mer
Projektverktyg
Jag har skapat ett enkelt projektverktyg för att bättre hålla reda på alla delprojekt. Vad du ser nedan är enbart en publik vy över innehållet i min projekt-hanterare. Där visas olika delprojekt samt hur mycket tid jag spenderat på respektive del. Jag har möjliget att lägga in kommentarer samt selektiv skärmdump som hamnar direkt här i form av bild. Systemet är helt integrerat med mina övriga verktyg och denna sida uppdateras därför automatiskt i realtid.
Dokumentation
dokumentation:
Avser processen att systematiskt dokumentera systemets egenskaper och specifika komponenter för framtida referens. Del av att vara en "vuxen programmerare". Dokumentation ska dock också tjäna syftet att vara en kreativ aktivitet i konceptuellt tänkande, annars är jag inte intresserad. Därför är det viktigt att verktygen för dokumentation är flexibla för att vara hängivna tankarnas rytm och inte bara en mekanisk process. Använder detta verktyg.
No comments yet.
Lager 1
lager 1:
Första direkta initiativet för att sätta ihop allt till en minimal fungerande version. Innefattar Databas, Websocket Node server, frontend Javascript, minimalt UI/UX. Det visar sig att strukturen jag planerade för databasen är mycket bra, samt att jag redan planerat och skapat grundläggande arkitekturen för Node servern. Servern i övrigt är också i tillräcklig ordning. Saknar fortfarande 50% eller mer av allt basalt som jag vill ha klart men får fixa det stegvis.
Skapa detta aktivitetsverktyg
Bugfix
Bugfix
Bugfix och UI-förbättring.
td [ ] auto-lägg-till [ ] syntax för kommentarer med td prefix.
td [ ] metod for att skriva in todo på projekt även om incheckad på annat projekt utan behöva check ut/in.
Doc
doc:
System, princip, disciplin och metod för hur dokumentera källkod och annat. Utan dokumentation är det svårt att förstå och underhålla programkod. Dokumentation är basal komponent i alla projekt men ofta dåligt implementerad med allt från obefintlig och förvirrande till onödigt expressiv och tidskrävande. Syftet här är att lägga grunden för en personlig tradition för dokumentation. Min personliga dokumentationsrutin har varit mycket knapphändig, men Linux är bästa miljön för att utveckla det, eftersom den som saknar struktur och personlig dokumentation straffas hårt via oväntade och självförvållade systemfel. Samma princip gäller dock inom programmering generellt sätt. Dokumentering tar lite mer tid men sparar mycket tid i längden. Den kloke förstår att dokumentation inte bara handlar om att beskriva saker, men att träna ens bedömmningsförmåga i att avgöra ett fenomen och kategorisera dess innehåll, vilket tränar förmågan och vanan att upprätthålla ett mer medvetet förhållningssätt till sin omgivning där ett fenomen förstås mer än det antas. Via ökad förstålese uppstår en högre grad av system-intuition för hur systemen kan utvecklas vidare. Dokumentation är därmed också ett sätt att träna upp perception (hur vi förstår världen) vilket gynnar tankeförmåga och handlingskraft.
Tog mer tid än planerat, men det blev bra och är en fundamental komponent som kommer bestå och fortsätta förbättras över tid. Systemet är halvautomatiskt och uppdateras i enlighet med min programkod.
Färdigt gränssnitt för referensmaterial som projektet generear och behövs för att kunna förstå, utveckla och underhålla systemet. Jag kunde inte integrera det i min terminal-miljö inom rimlig tid så jag gjorde ett WebUI istället. ChatGPT gjorde dock en Vim-key kompatibelt läge för mig i textarea-elementet (ytterst basalt men tillräckligt).
Hur har jag i skrivandets stund lyckats förlora 4 timmar på detta? Känns orimligt. Tidsuppfattningen har påverkats. Fälla med AI. Vissa problem kan den inte lösa, men skapar en känsla av att du nästan har lösningen och man försöker igen och igen men får bara mer problem. AI är bra för göra häst-jobb, att utvärdera referensmaterial, och för reflektion men inte för att förlita sig på. Behöver motverka detta beteende mönstret att fastna i AI.
Skapa en gammal hederlig Web-lösning som "fallback-lösning". Jag måste ha ett dok-system för källkod. Skapa ett WebUI för dokumentering som körs i webläsare paralellt. Dokumentation är ändå mer av konceptuellt tänkande och är inte beroende av hypereffektiva tangentbordskommandon, även om det är trevligt.
Avbryter det försöket att skapa 100% integrerad lösning. Jag saknar domänspecifik kunskap (Tree-sitter m.m) för att kompensera för AI's svårighet att lösa det. Jag löser det "fint" i framtiden i mån av tid och behov.
Holistiskt perspektiv
Med anledning av #c242 behöver jag metod för att inte förlora tidsuppfattning vid krävande arbete. Till skillnad från djupfokus som är produktivt och inte ska störas, så finns det andra typer av arbete som i vidare reflektion visar sig vara onödigt eller fruktlöst arbete, och som måste utvärderas och avbrytas under pågående arbete. Mät pågående arbete mot den aktuella tidsåtgången. Det är ett sätt att omvärdera processen och byta riktning om det behövs.
Async Mutex Pipes
async mutex pipes:
Egen modell för asynkron kommunikation in Javascript system. Ersätter det inbyggda event-systemet. Bygger på tidigare arbete. Visat sig vara mycket effektivt i praktiken.
Ordna en central dispatcher för signalhantering.
Signalbaserad kommunikation ska bara meddela att något hänt, inte skicka data, så att varje komponent själv hämtar sin information och förblir helt oberoende. Sändare bryr sig inte om mottagare. Mottagare ansvarar för att hämta data via publika gränssnitt. Data ska ej skickas via AMP. Leder till hårt kopplad och svår kod (erfarenhet, och AMP är menat att lösa det).
Logserver
logserver:
Har ett internt loggsystem för all utveckling. Vilken komponent jag än utvecklar kan skicka diagnostik och loggar till ett centralt system. Att göra debug i nvim, javascript, databas, server, php, ajax, etc. är annars svårt. Att lägga tid på att installera, underhålla och lära sig separata konventionella system för varje enskilt område är inte alltid effektivt och tar mer tid i slutändan.
td [ ] Fixa nvim logsystem när server inte är tillgänglig (stannar).
Fungerar. Nvim (eller vad som helst) till lokal "pipe" -> lokal server läser pipe och skickar till central server -> central server vidarebefordrar till klienter som lyssnar på loggserver -> klienter ex webui, 🔗 tui, visar loggar i realtid.
Unix Domain Sockets är svårare än Websockets för att hantera hög-tryck och flera klienter på realtid-diagnostik-system. Ska återgå till tidigare fungerande lösning med websockets med webui för realtids-diagnostik. Kan göra CLI klient med interface mot websocket servern för integrering med lokala verktyg om befintligt webui inte är bekvämt nog.
GitHub logistik
Återskapat git-historik
Organisera katalogstruktur
td [ ] Behöver slutföra standardiseringen av ordningen för mina filer och kataloger som innefattar innehåll i alla avseenden, inte minst kod och konfigurationer. Etablera koncept test-filer, arkiv, projekt, dev, backup.
phxm
td [ ] Php formatter för nvim inte installerad, eller fungerar inte.
td [ ] Möjlighet att binda projekt-specifika kommandon (ex make; make install...) för ett projekt till tab-index menyn till vänster (flash-bindings), ex nummer indexet, som öppnar och kör kommandot i en ctxterm Alternativt skapa ett nvim-plugin som läser från en UDS och uppdatterar bubblecol-flashbindings, varav fish kan skicka senaste kommandot till PhxM IDE.
td [ ] Öppna ctxterm cd till symlink include dir, och om flera, presentera möjlighet att välja. Då bättre öppna i phxm projekt baskatalog, och integrera symlink katalog-väljare i fish, för att inte kräva dialog varje gång ctxterm öppnas, då syftet är att snabbt åtkomma en terminal.
td [ ] Integration för hoppa till include-kataloger, (fish integration, men bättre i phxm och låta en ctxterm kvarvara i sin katalog). Kanske telescope filter-selector för befintliga ctxterms.
Lokal utvecklingsmiljö
td [ ] Fish shell skriver ut info om det finns en fördefinierad info-fil i nuvarande katalog.
td [ ] vim.treesitter.language.require_language() is deprecated. Run ":checkhealth vim.deprecated" for more information
Metod för designval efter behov
Mins att jag skapade 🔗 trm-workflow, vilket jag framgångsrikt använder nu (detta systematiska och flexibla självreflektionsverktyg som också strukturerar alla mina projekt och tillåter snabb kontext-byte utan fokusförlust). Dock behövs nu ett väldigt specifikt kognitivt verktyg för att eliminera risken att förlora tid genom att överarbeta ett givet system.
Skapa en ontologi för att bedöma ett systems komponenter och dess nödvändighet i relation till ett ändamål. En ontologi för det generella behovet har jag redan skapat 🔗 socm-ontology. Vad som behövs är ett specifikt kognitivt verktyg som med precision applicerar den ontologin på detta specifika problemområde: att bedöma vilka komponenter som ska ingå i ett datorsystem. Den generella ontologin svarar dock redan mot det behovet. Vad som behövs här är en konkret applicering av den ontologin.
Med anledning av #1c0c ska jag utveckla metod för att bättre undvika att gå i samma fälla igen där jag går från en "kan vara bra att ha" mentalitet till en "är absolut nödvändigt". Behöver någon sorts systematik för det samt diciplin att fökja det.
Brandvägg
Har gjort för komplicerad design. För mig okänd detalj skapar negativ kedjereaktion som undgår min kunskap.
Brandväggen fungerar ej som tänkt. Regler appliceras inte som tänkt.
"Mjukat upp" brandväggen för att möta behov. Fixat bugg.
Ännu mer härdad brandvägg. Behöver dock systematisk genomgång framöver för säkerställning.
Justera övervägningsprocessen. Är ofta ett dilemma att antingen bygga egna lösningar eller gå på djupet med ett enskilt verktyg. Vad som är effektivast är inte alltid självklart. Tummregel är att lita på välkända verktyg och lägga tid på att lära sig dem. Det ger bättre avkastning på sikt även om kortsiktig förlust i den specifika avsikten, då kunskapen består och sannolikt gynnar i framtida ärenden (förutsatt att verktyget är "etablerad tradition"). Brandväggen jag använder har bra inbyggda verktyg som överlägset ersätter endel tidigare lösningar jag funderat på.
Lär mig Docker Compose
doc:
System, princip, disciplin och metod för hur dokumentera källkod och annat. Utan dokumentation är det svårt att förstå och underhålla programkod. Dokumentation är basal komponent i alla projekt men ofta dåligt implementerad med allt från obefintlig och förvirrande till onödigt expressiv och tidskrävande. Syftet här är att lägga grunden för en personlig tradition för dokumentation. Min personliga dokumentationsrutin har varit mycket knapphändig, men Linux är bästa miljön för att utveckla det, eftersom den som saknar struktur och personlig dokumentation straffas hårt via oväntade och självförvållade systemfel. Samma princip gäller dock inom programmering generellt sätt. Dokumentering tar lite mer tid men sparar mycket tid i längden. Den kloke förstår att dokumentation inte bara handlar om att beskriva saker, men att träna ens bedömmningsförmåga i att avgöra ett fenomen och kategorisera dess innehåll, vilket tränar förmågan och vanan att upprätthålla ett mer medvetet förhållningssätt till sin omgivning där ett fenomen förstås mer än det antas. Via ökad förstålese uppstår en högre grad av system-intuition för hur systemen kan utvecklas vidare. Dokumentation är därmed också ett sätt att träna upp perception (hur vi förstår världen) vilket gynnar tankeförmåga och handlingskraft.
td [ ] Gör utvärdering på Docker, trade-offs etc. Docker förenklar installationer. Jag gillar inte när system är för enkla, för det betyder oftast lägre grad av kontroll inflytande, vilket i sig leder till värre komplexitet på sikt då de svarar dåligt mot ökade krav från närliggande system.
Saknar robust systematik för översikt och utvärdering av teknologier (ex Docker har jag ignorerat, Ansible har jag utvärderat). Att vara oinformerad kan leda till onödigt besvär.
Gör allt utan docker, men vissa saker är enklare att testa med docker. Är i dagens läge osäker på vart jag placerar Docker i min system-metodologi.
Server utvecklingsmiljö
td [ ] Behöver göra terminal-gränssnittet på servern mer likställt med lokal konfiguration. Ex. ctrl + f/t för fzf funkar ej i fish.
Cred, färdigställ hela processen
används för autentificiering och sedan upp/ned laddning av backup arkiv, kan automatiseras och integreras med det mesta.
Gjort samma misstag igen som 6/Jun. Hade viktig fil förlorad i migration av data. Git laddar ej upp test-filer som förväntat. Viktig fil i katalog för test-data. Återställt repo från Git. Därmed fil i test-katalog förlorad. Åter igen räddad av en annan gammal ad-hoc backup.
Raderade cred.vault av misstag vid organisering. Räddad av ad-hoc backup.
Överväg CDN
Ingen koll på brandväggs-loggar. Förslag: System för översikt. (FW har regler som skriver loggar).
Saknar unison strategi för hantering av blockerade ip (bottar etc). FW, Web, cron (?) lägger till adresser, med olika tidsspann.
Uppdaterat regler för brandvägg.
Migration från CloudFlare, förnya certifikat etc.
Skippar CloudFlare, onödig koplexitet som ger problem vars tidsåtgång inte motiverar fördelarna i dagens läge.
Mindre tekniska åtgärder
Glömmer make install innan jag testar uppdatering.
Bugfix i 🔗 permtermbuf.nvim. Tack GPT o3. "TL;DR: Du försökte köra en terminal i en buffer som inte var en riktig terminalbuffer. Nu låter du :terminal själv skapa buffern – och då fungerar det."
Processoptimering, TRM-workflow och SoCM-ontology
processoptimering:
Syftet är att optimera projektutvecklingsmodellen för utveckling av detta projekt (Matkalkyl).
Ursprungs-ontologin som meta-modellen TRM-workflow baseras på, vilket Matkalkyls projektutvecklingsmetod i sin tur baseras på. SoCM är en funktionell universiell ontologisk arkitektur som beskriver den generativa strukturen hos alla begreppsmodeller---inklusive sig själv, och är därmed också själv-reflexiv. Den är funktionell på så vis att den används för att systematisera människans strukturering av förståelse för att skapa uttömmande perceptuell klarhet av ett subjekt.
Syftet är också att öka graden av medvetande---med andra ord: meta-kognition; att tänka kring tänkandet---genom att återkommande klassificiera process-relaterad information---att identifiera relevanta intryck och dela in dem i kategorier. Ökar förmågan att se strukturer i processer.
Utökat !🔗 trm-workflow med kategorier för projekt-anteckningar. Ökad struktur.
Ser över hur kommentarer i projekt-korten (exempelvis denna) skrivs bättre för ökad precission och relevans.
Besluta mellan BlackBlaze och Storj
BlackBlaze eller Storj. Val är irrelevant – leverantör ska lätt kunna bytas ut. !🔗 cred stödjer båda eller se till det.
Agile och Scrum
Scrum är trademark och för snävt. Egen metod (TRM) bättre anpassad till mitt holistiska perspektiv. Agile har värde.
Undersök Agile och Scrum som möjliga metoder, anpassade till mina omständigheter. Syfte: hitta komplett lösning för utveckling.
Skapa process modell för mjukvaruutveckling
!🔗 trm-workflow klar.
Skapa den rutin inom vilken all utveckling sker. Metod för att rikta insats, samt hålla koll på alla del-projekt.
Nyhetsbrev
Skriver för Juni
Kuben
Den tredimensionella kuben ovanför kan uppfattas på olika sätt beroende på perspektiv och hur hjärnan tolkar djup och vinklar. Den optiska effekten uppstår eftersom kubens linjer och hörn kan tolkas på flera sätt, vilket gör att den verkar skifta form eller riktning.
Tack vare #4315: Börja med högkvalitativ men icke överflödig dokumentation av befintlig kod då det börjar bli nödvändigt. Närminnets gränser är redan passerade.
Skapa minsta möjliga grafiska gränssnitt för fungerande version.
Första test-användaren i databasen är registrerad. Saker faller på plats.
Lager 1 - Databas, websocket front/backend, och API. Det mest grundläggande.